AN  OPERATIONAL  PLANNING  INFORMATION  SYSTEM 

FOR  SMALL  COMMUNITIES 


DECEMBER     1969  -  NUMBER  34 


BY 

R.J.  MAXMAN 

a 

W  L.GRECCO 


JOINT  HIGHWAY  RESEARCH  PROJECT 

PURDUE    UNIVERSITY     AND 

INDIANA     STATE    HIGHWAY     COMMISSION 


Technical  Paper 
AW  OPERATIONAL  PLANNING  DTFCRMATION  SYSTEM  FOR  SMALL  COMMUNITIES 


TO:    J.  Po  Mclaughlin,  Director 

Joint  Highway  Research  Project 

FROM:  Ho  Lo  Michael*  Associate  Director 
Joint  Highway  Research  Project 


December  30,  I969 


File  No. :  3-7 


The  attached  Technical  Paper  "An  Operational  Planning  Information 
System  for  Small  Communities"  has  been  prepared  by  Messrs,  Robert  J, 
Maxman  and  V7illiam  L-  Greece  The  paper  was  prepared  from  JHRP  Information 
Report  No.  5»  March  1968.  The  research  for  this  paper  was  funded  by  the  " 
Public  Health  Service  through  the  Environmental  Health  Institute  of 
Purdue  University. 

The  paper  has  been  accepted  for  presentation  at  the  U9th  Annual 
Meeting  of  the  Highway  Research  Board  January  1970.  It  will  be 
published  by  the  Board  during  1970.  The  paper  is  presented  to  the  Board 
for  information. 

Respectfully  submitted s 

Harold  L.  Michael 
Associate  Director 


HLMsms 


cc:     P.  L.  Ashbaucher 
W.  L„   Dolch 
W.  H.  Goetz 
W.  L.  Grecco 
G.  K.  Hallock 
M.  E.  Harr 


R.  H.  Harr ell 
J.  A.  Havers 
V.  S.  Harvey 
P.  B.  Meadenhall 
R.  D.  Miles 


C.  P.  Scholer 
M.  Bo  Scott 
W.  T.  Spencer 
H.  R.  J.  Walsh 
K,  B.  Woods 
E.  J.  Yoder 


Digitized  by  the  Internet  Archive 

in  2011  with  funding  from 

LYRASIS  members  and  Sloan  Foundation;  Indiana  Department  of  Transportation 


http://www.archive.org/details/operationalplannOOmaxm 


AN  OPERATIONAL  PLANNING  IHFORMATION 
SYSTEM  FOR  SMALL  COMMUNITIES 

R.  J.  Maxman,  Transportation  Planner,  Montgomery-Green  County  Transportation 
and  Development  Planning  Program..  Dayton,  Ohio  and 

W.  L.  GreccOj  Professor  of  Civil  Engineering,  Purdue  University. 

INFORMATIVE  ABSTRACT 

The  wealth  of  data  collected  on  the  urban  area  by  a  multiplicity  of 
people  for  a  multiplicity  of  purposes  has  led  to  an  inefficient,  disorganized 
utilization  of  resources  for  data  handling.  Until  recently,  most  of  the 
information  collected  has  been  gathered  by  a  specific  group  for  a 
specific  purpose.  This  information  was  not  useable  by  other  than  the 
primary  data  recipient  because  of  its  narrow  definitions  and  specific 
characteristics . 

Provided  herein  is  a  system  whereby  data  that  are  collected  only  once 
are  useable  by  all  segments  of  the  urban  environment.  Universally 
compatible  definitions,  aggregation  unit,  and  procedures  are  developed. 
Computer  programs  were  developed  to  handle  the  data  for  the  system.  The 
Environmental  Data  Storage  and  Retrieval  System  (EDSARS)  will  make  a 
useful  tool  for  all  segments  of  the  urban  environment  by  putting  all 
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generally  useable  data  in  one  place  with  one  set  of  definitions  and 
aggregated  on  one  useful  module,  utilising  one  set  of  data  handling 
procedures.   The  basic  unit  of  data  collection  was  established  on  a  parcel 
basis,  thereby  providing  a  high  degree  of  flexibility  in  data  aggregation. 

The  conceptual  development  of  information  theory  as  it  applies  to 
urban  data  systems  was  first  explored ,  The  actual  conceptual  development 
of  EDSARS  is  explained  next.,  followed  by  the  operational  procedures  needed 
to  utilize  the  EDSABS  system, 

INTRODUCTION 
DATA  NEEDS 

Fundamental  to  the  planning  process  is  the  development  of  alternative 
plans  which  are  provided  to  the  decision  maker  for  action.  These  plans 
develop  as  a  result  of  thorough  analysis  of  proper  and  sufficient  data. 
Analyses  are  good  as,  but  no  better  than  the  data  quality.  The  present 
trend  seems  to  be  to  seek  more  symtomatic  relationships,  which  implies 
more  data  variables.   Today  it  appears  almost  natural  for  researchers  to 
add  additional  variables  to  the  correlation  analysis  for  the  purpose  of 
increasing  the  amount  of  variability  of  the  dependent  variable  that  can 
be  explained.   In  spite  of  the  general  knowledge  of  the  costliness  of 
data  collection,  more  data  are  being  collected  by  more  people  for  more 
reasons  than  ever  before. 

The  value  of  data  for  proper  analysis  is  not  under  question.   The 
critical  point  is  the  efficiency  of  the  entire  data  system,  not  from  the 
standpoint  of  an  individual  user  but  in  terms  of  total  system  costs.   Data 
are  being  collected  on  many  aspects  s  from  the  individuals '  health  to  the 
number  of  trips  he  makes.  In  the  past,  most  of  this  information  has  been 
gathered  by  a  specific,  agency  for  a  specific  use,  each  agency  applying  its 
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own  individualized  definitions  to  the  data.  For  example,  definitions  of 
land  use  density  can  range  from  trips  generated  per  acre  to  persons  per 
square  foot  of  floor  space.  The  definition  has  always  depended  upon  the 
information  user.  This  multiplicity  of  data  definitions  and  uses  results 
in  a  hodgepodge  of  data,  collected  many  times  by  many  agencies  and  many 
times  without  knowledge  of  each  other's  efforts  (l)*. 

Public  agencies  gather  much  of  their  data  for  normal  operations  5 
these  data  could  be  very  useful  to  other  agencies  at  little  additional  cost, 
if  only  common  definitions  and  parameters  could  be  established.  Without 
these  common  definitions  and  parameters  it  is  difficult  for  each  agency  to 
visualize  the  urban  environment  except  in  the  perspective  of  its  own 
narrowly  defined  information  requirements. 

Each  urban  area  has  developed  a  multiplicity  of  plans  to  channel  the 
growth  of  the  area  in  a  manner  that  is  deemed  best  for  the  community  as  a 
whole.  Up  to  the  present,  just  as  the  different  agencies  collect  and  use 
their  own  data,  so  do  the  various  urban  studies.  While  a  Recreational  or 
School  Plan  may  use  much  of  the  data  collected  in  a  Transportation  Study, 
the  difference  in  data,  definitions  and  aggregation  units  makes  the  information 
nearly  useless  for  any  study  other  than  the  one  that  collected  the  data. 

There  are  many  segments  of  the  urban  environment  which  desire  infor- 
mation on  the  community.  The  present  means  of  getting  this  information  is 
for  each  to  go  out  into  the  urban  area  and  collect  the  data  directly.  Any 
company,  organization,  or  group  that  presently  wants  data  on  the  community 
must  collect  the  information  itself  or  accept  the  narrow  definitions  of  the 
data  now  established  by  existing  governmental  groups  or  studies. 


^Numbers  in  parenthesis  refer  to  numbers  in  list  of  references, 
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In  order  to  facilitate  the  use  of  data  by  other  than  the  primary  in- 
formation receiver,  a  set  of  universally  compatible  definitions  is  needed. 
This  set  of  definitions  is  not  impossible  to  develop  if  one  attempts  to 
direct  the  collection  of  "pure"  data.   The  term  "pure"  simply  means  that 
the  information  should  not  be  aggregated  before  collection.  For  instance, 
when  square  feet  of  space  is  collected,  it  should  be  recorded  as  square 
feet,  not  square  feet  per  some  other  dimension.  For  example,  square  feet 
per  employee  may  be  useful  to  an  industry,  but  square  feet  of  building  and 
number  of  employees  is  much  more  useful  for  planning  purposes  while  still 
serving  the  original  purpose. 

The  data  system  that  is  described  below  seeks  to  develop  a  tool  for 
urban  decision  making  that  utilizes  data  from  many  sources  and  makes  this 
information  available  and  useable  by  other  sectors  of  the  urban  community. 

The  Scope 

The  project  described  involved  the  development  of  an  urban  data  system 
for  an  area  of  approximately  100,000  population.  The  Lafayette-West 
Lafayette  area  was  used  to  demonstrate  the  application  of  the  developed 
system.  The  Greater  Lafayette  area  had  under  consideration  the  conduct  of 
a  Land  Use  and  Transportation  study.  In  anticipation  of  the  development  of 
these  data,  this  planning  information  system  was  developed.  The  system  was 
to  be  much  broader  than  the  proposed  study  and  is  referred  to  as  the 
Environmental  Data  Storage  and  Retrieval  System  (EDSARS). 

The  first  developmental  problem  involved  choosing  the  degree  of  sophis- 
tication needed  for  such  a  system.  This  involved  choosing  a  particular 
level  in  a  hierarchy  of  data  system  complexity.  Once  the  level  of  sophis- 
tication had  been  decided,  the  basic  data  collection  and  aggregation  module 
was  chosen.  The  data  to  be  used  was  decided  along  with  specific  definitions 
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for  each  data  item.  The  methodology  for  entering  these  data  into  the 
system  was  developed  along  with  updating  procedures  to  keep  information 
current.  A  logical  and  easily  useable  means  of  data  storage  and  retrieval 
was  developed  to  facilitate  the  use  of  the  system  by  a  wide  variety  of 
users  . 

DESCRIPTION  OF  EDSARS 

Level  of  Data  Sophistication 
The  information  used  in  the  Environmental  Data  Storage  Retrieval 
System  (EDSARS )  is  taken  from  the  level  in  data  hierarchy  of  a  data 
library.   Banked  data3  which  is  another  level  in  the  information  hierarchy , 
are  organized  into  machine  records  but  need  not  be  functional  or  logical 
in  format.  Raw  data  make  up  the  lowest  level,  of  data  sophistication. 
These  data  are  not  machine  digestable  and  therefore  are  not  useable  in  an 
organized  data  system.  The  data  library  information  is  logical  and 
functional  in  format  and  can  be  updated,  searched,  and  retrieved;  these 
requirements  are  essential  for  any  urban  data  system. 

Level  of  System  Sophistication 
The  three  levels  of  system  sophistication  vary  in  the  complexity  of 
models  incorporated.  The  first  level  uses  no  models,  the  second  utilizes 
specialized  models s  while  the  third  level  uses  simulation.  EDSARS,  being 
an  attempt  at  developing  the  initial  phase  of  an  urban  data  system,  utilises 
the  first  level  of  sophistication.  The  system  contains  tabulated  data  but 
no  specialized  or  simulation  models.  It  is  felt  that  the  model  requirements 
will  evolve  from  the  demands  of  the  users  on  the  data  system.  The  addition 
of  models  to  the  system  can  be  made  within  the  present  format;  the  data  in 
the  system  will  directly  feed  any  models  developed  in  the  future. 
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The  computer  hardware  that  is  incorporated  also  influences  the  level 
of  system  sophistication.  EDSAES  utilises  the  CDC  6500  computer  at  Purdue 
University.  This  is  a  general  purpose  computer;  the  programming  language 
used  is  Chippewa  Fortran.  The  data  system  can  be  initialized  and  information 
retrieved  or  updated  by  merely  submitting  the  correct  program  deck  to  the 
computer  science  center.  The  updatingj  retrieval  or  initialization  will 
be  run  just  as  any  other  job  that  is  submitted  to  the  computer.  The 
information  for  EESABS  is  now  stored  on  tape.  As  the  system  is  initialized 
and  the  amount  of  stored  information  grows,  the  incorporation  of  a  !tdisk 
pack"  will  become  feasible.  A  "disk  pack"  is  a  mountable  disk  storage  device 
that  enables  random  access  of  information.  This  direct  access  feature  will 
save  valuable  computer  time  when  the  system  searches  large  quantities  of 
data. 

The  decisions  on  the  level  of  system  sophistication  were  the  result  of 
many  factors.  Models  were  not  incorporated  into  the  system  because  of  the 
necessity  of  actual  data  to  test  the  validity  of  a  model.  This  project 
outlines  the  initialization  of  EBSAES  without  actually  inserting  real  data. 
The  amount  of  data  needed  to  initialize  the  system  makes  initialization 
another  entire  project  of  at  least  one  to  two  years  in  duration.  Once  the 
initialization  is  complete 9  then  the  addition  of  models  can  be  censidered. 

The  decision  of  using  the  CDC  65OO  computer  was  made  in  light  of  the 
hardware  available.  Purdue  University  now  has  an  IEM  709^  computer  which 
could  handle  a  data  system  such  as  ED3ABS.  However 9  the  709^  is  a  second 
generation  computer ;  this  type  of  computer  is  now  in  the  process  of  being 
phased  out  by  many  organizations;  being  replaced  by  a  "third  generation" 
computer  such  as  the  CDC  6500  computer.  Any  work  done  in  the  future  on  data 
systems  will  most  probably  be  done  on  the  more  advanced  equipment  such  as 
the  CDC  6500.  The  use  of  Chippewa  Fortran  was  the  result  of  the  authors' 
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knowledge  of  the  language  and  the  fact  that  the  Fortran  developed  for  the 
CDC  system  is  quite  efficient  in  its  data-handling  capabilities. 

Data  Module 

The  data  module  chosen  for  EXSAES  is  the  parcel.  This  aggregation 
module  seems  to  be  almost  the  universal  choice  by  existing  urban  data 
systems.  The  parcel  provides  a  flexible «,  multi-purpose  base  from  which  to 
work.  The  data  to  be  incorporated  into  an  urban  data  system  are  easily 
keyed  to  the  parcel.  The  tagging  methods,  which  will  be  discussed  below, 
work  well  with  the  parcel  module.  The  parcel  forms  a  very  useful  aggregation - 
unit  in  that  it  is  the  largest  common  denominator  that  can  be  used  to  build 
zones.  Any  zone  in  an  urban  area  can  be  represented  fairly  accurately ,  by 
a  composite  of  parcels.  This  gives  the  system  maximum  flexibility  in  the 
designation  of  zones  while  containing  a  minimum  number  of  data  units. 

The  parcel  in  EDSARS  is  defined  as  all  contiguous  land  under  one 
ownership  and  one  general  land  use.  This  definition  closely  parallels  the 
parcel  used  in  assessors'  records.  If  two  adjacent  pieces  of  land  are  owned 
by  the  same  person  and  used  for  the  same  purpose,  they  would  be  listed  as 
one  parcel.  If  two  adjacent  parcels  had  different  uses,  they  could  be  listed 
as  two  parcels.  This  definition,  being  general,  allows  a  certain  measure 
of  ambiguity  in  the  designation  of  a  parcel;  the  system  has  the  facility, 
however,  of  being  able  to  join  two  or  more  parcels  Into  one  new  parcel,  or 
break  up  one  parcel  into  two  or  more  parcels.  This  facility  for  redefining 
parcels  allows  the  system  to  establish  its  own  equilibrium  as  the  data  are 
used  and  reevaluated. 

A  special  definition  of  the  parcel  is  utilized  when  coding  rights-of- 
way.  Each  street  segment  and  utility  right-of-way  is  coded  just  as  any 
other  parcel.  A  street  or  right-of-way  is  broken  down  into  block  long 
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segments  if  the  block  length  is  500  feet  or  less ;   if  the  block  length  is 
longer-  than  500  feet,  the  block  is  broken  down  into  segments  of  500  feet  or 
less.  An  intersection  is  taken  as  a  street  parcel*  The  parcel  boundaries 
are  defined  as  the  right-of-way  line  for  the  street  segments,,  An  example 
of  an  area  divided  into  parcels  can  be  found  in  Figure  1„ 

Data  'ragging  Methods 

EBSARS  uses  both  the  name  method  and  location  method  of  tagging  data . 
The  name  tag  utilized  is  the  street  address  of  a  building  or  empty  parcel* 
The  street  number,  name  and  tjrpe  (e.g..  Drive,  Street,  Lane,  etc)  are  all 
noted  in  the  name  tag  of  the  parcel  or  building*  For  rural  areas,  the 
street  number  is  replaced  by  the  rural  route  number,  and  the  street  name  is 
replaced  by  "Rural  Route."  The  name  method  of  tagging  gives  the  system 
the  facility  of  locating  data  for  the  user  on  a  basis  that  is  familiar  to 
all  segments  of  the  urban  environment,,  Street  addresses  are  universally 
known  and  understood,  and,  therefore,  enable  all  potential  users  to  be 
familiar  with  at  least  one  retrieval  method. 

Street  segments  are  coded  by  the  street  name  and  the  number  (in 
hundreds)  of  most  of  the  houses  on  the  street  segment.  A  street  segment 
along  a  street  called  Main  Street,  where  house  numbers  go  from  100-225 
would  be  coded  as  100B  Main  Street.  This  indicates  that  this  is  the  one 
hundred  block  of  Main  Street.  This  gives  the  benefits  of  the  name  tag  to 
street  segments  as  well  as  individual  parcels  and  buildings. 

The  location  tag  utilized  by  EPSAES  is  a  rectangular  grid  coordinate 
system  which  is  superimposed  over  the  entire  development  area.  The  grid 
coordinate  uses  one  foot  as  the  basic  unit.  The  parcels  and  street 
lengths  are  tagged  by  the  coordinates  of  their  approximate  eentroid.  The 
actual  digitizing  of  the  coordinates  is  accomplished  by  an  automatic 
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coordinate  digitizer.  By  utilizing  a  location  tag,  internal  logic  is 
added  to  the  data  in  EDSARS.  The  coordinates  facilitate  the  retrieval  of 
data  on  an  areal  basis,,  Data  for  certain  geographical  segments  of  the 
development  area  can  be  directly  retrieved  with  the  use  of  the  coordinates. 
Density  computations  become  immediately  possible  with  the  use  of  coordinates. 

The  utilization  of  rectangular  grid  coordinates  provides  another  very- 
useful  capability,,  A  zone,  such  as  a  Census  Tract  or  Transportation  Zone, 
can  be  represented  by  the  grid  coordinates  of  its  boundary.  This  is 
accomplished  by  representing  the  zone  by  a  series  of  triangles  and  digitizing 
the  coordinates  of  the  vertices.  By  representing  zones  in  this  way,  a 
dictionary  of  zone  names  and  grid  coordinates  is  developed.  When  any 
information  is  desired  on  a  zonal  basis,  the  coordinates  of  the  zone  are 
read  and  each  parcel  is  tested  to  establish  whether  or  not  it  lies  within 
the  zone  in  question.  The  information  for  each  parcel  within  the  zone  is 
then  retrieved  and  aggregated  thereby  giving  information  on  the  desired 
zonal  basis.  Figure  2  shows  a  zone  broken  into  triangles  for  coding. 

In  order  to  coordinate  the  actual  data  incorporated  into  the  system 
and  the  tags  for  each  parcel,  a  dictionary  with  the  parcel  number,  building 
number,  and  street  address  (or  block  number  for  street  segments')  developed. 
Another  file  coordinating  each  parcel  number  and  grid  coordinate  is  then 
initialized.  The  actual  data  are  stored  in  conjunction  with  a  parcel  number. 
The  data  are  related  to  the  name  and  location  tags  through  the  parcel 
number-building  number-street  address  dictionary  and  the  parcel  number-grid 
coordinate  dictionary.  The  parcel  number  is  merely  a  unique  number  of  1 
to  6  digits  given  to  each  parcel.   The  numbers  need  not  be  consecutive  or 
have  any  logical  order.   The  only  requirement  is  that  each  parcel  have 
one  and  only  one  unique  number. 
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Data  Dimensions 
The  definition  of  land  use  developed  by  the  Metropolitan  Washington 
Council  of  Governments  was  utilized  to  aid  in  determining  the  data  needed 
to  define  the  different  areas  of  land  use.  Data  were  examined  in  the  light 
of  how  well  they  defined; 

1.  Type  of  activity 

2.  Type  of  structure 

3.  Type  of  land  use 
ho     Intensity  of  use 

5o  Aesthetic  qualities 

6*  Restrictions  en  use 

7°  Nuisance  characteristics 

8„  Economic  functions  (2) 

In  order  to  completely  describe  the  urban  environment,  the  information 
on  each  parcel  is  broken  down  into  three  categories : 

1.  Parcel  Information  -  information  on  the  parcel  itself,  including 
dimensions ,  restrictions,  zoning,  use,  etc. 

2„  Building  Information  -  information  on  each  building  on  a  parcel, 
including  age,  value,  type  of  construction,  condition,  size,  etc. 

3»  Establishment  Information  -  specific  information  on  each  unit 
within  a  building  such  as  a  business,  a  dwelling  unit,  ete„,  including 
space  use,  number  of  employees,  number  of  residents,  age  of  residents, 
number  of  vehicles,  etc. 
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I.  Parcel  Information 

1=  Land  use 

2.  Ownership 

3  o  Frontage 

k „  Area 

5.  Year  of  subdivision 

6„  Assessed  value  of  land 

7»  Easement 

8 .  Landmark 

9.  Neighborhood  characteristics 

10.  Land  appearance 

11.  Number  of  structures 

12.  Year  of  zoning  change 

(The  following  data  are  collected  for  street 

25.  Intersection 

26.  Length  of  segment 

27.  Right-of-way  width 

28.  Pavement  width 

29.  Functional  class 

30.  Structural  composition 

31.  Per  cent  grade 

32.  Average  daily  traffic 

33.  Number  of  accidents 

3^.  Traffic  control  signs  and  signals 


13.  Zoning 

lU.  Zone  change  request  number 

15.  Variance  number 

l6o  Comprehensive  Plan  use 

17.  Utilities 

18.  Parking  spaces 

19.  Loading  area 

20.  Assessed  value  of  improvements 

21.  Total  assessed  value 

22.  Sale  date 

23.  Sale  price 
2U.  Nuisances 
segment  parcels) 

35.  Speed  limit 

36.  Curb  parking  regulations 

37.  Curb  type 

38.  Sidewalks 

39«  Number  of  lanes 

Uo.  Loading  zone 

Ul.  Bus  route 

^2.  School  route 

h-3°  Access  control 

kh.  Condition 


Maxman  -  Greeco 


12 


II.  Building  Information 

1.  Year  built 

2.  Type  of  construction 

3.  Type  of  structure 
k.     Building  condition 

5.  Year  of  latest  building  permit 

6.  Cumulative  cost  of  building 
permits 

To  dumber  of  floors 

8.  Total  floor  area 


9.  Basement 

10.  First  floor  area 

11.  Number  of  dwelling  units 

12.  Building  setback 
13»  Required  setback 
lU.  Rehabilitation  cost 


15 •  Type  of  building  code  violation 

l6„  Number  of  building  code 
violations 

17.  Number  of  establishments 


III.  Establishment  Information 

1.  Space  use 

2.  Total  number  of  employees 

3.  First  floor  area 
U„  Total  floor  areas 

5.  Number  of  rooms  for  rent 


6.  Number  of  residents  by  sex 
and  age  group 

7.  Family  income 


8. 

Vehicles  owned 

9* 

Police  calls 

10. 

Fire  calls 

11. 

Welfare  payment 

12. 

Number  of  communicable 

diseases 

13. 

Type  of  communicable 

diseases 

Ik. 

Rent 

Each  piece  of  data  that  was  entered  into  the  system  was  judged  tc  be 

important  to  the  planning  community,  able  to  be  updated,,  and  relatively 

easy  to  collect.  Data  that  were  too  expensive  to  collect  or  not  updatable 
were  not  incorporated  into  the  system. 
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OPERATION  OF  EDSAES 
Data  File  Characteristics 

The  data  in  EB3ARS  are  established  in  four  separate  files.  The  first 
data  file  contains  parcel  numbers  and  parcel  grid  coordinates .  Each  parcel 
is  given  a  unique  number  to  identify  it  as  a  data  entity;  this  number  is 
correlated  to  the  grid  coordinates  of  the  approximate  parcel  eentroid  by 
the  Parcel  Number-Grid  Coordinate  File.  The  second  data  file  contains 
the  parcel  number,  building  number  and  address  of  each  building  in  the 
system*  In  the  case  of  a  parcel  with  no  building,  the  building  number  is 
listed  as  zero.  Each  building  is  given  a  unique  number  on  a  parcel,  and 
coordinated  to  the  correct  address  by  the  Parcel  Number-Building  Number- 
Address  File-  The  third  data  file  contains  the  parcel  number  and  all 
general  data  on  that  parcel <>  The  data  for  each  parcel  are  correlated  to  the 
street  address  and  grid  coordinate  via  the  parcel  number.  The  fourth  data 
file  contains  zone  names  and  the  coordinates  of  the  zone  boundary. 

These  four'  data  files  make  up  the  data  storage  portion  of  EI6ARS.  The 
actual  data  is  stored  on  tape  and  can  be  manipulated  by  a  set  of  package 
programs ,  The  first  set  of  programs  is  used  to  initialize  the  system  by 
reading  cards  and  writing  the  information  on  tape.  The  second  set  of 
programs  is  used  to  incorporate  more  data  items  when  they  become  available. 
The  third  set  of  programs  is  used  to  read  the  data  tape  and  write  on  paper. 
This  set  of  programs  is  used  to  check  the  other  program  sets  and  to  give  a 
complete  list  of  all  data  in  the  system.  The  fourth  set  of  programs  is 
used  to  update  the  values  of  data  items  in  the  system  when  current  information 
becomes  available.  The  fifth  and  final  set  of  programs  is  used  to  retrieve 
information  from  the  system  for  special  user  purposes.  The  following  is  an 
explanation  of  the  package  programs  and  procedures  for  using  them  in  EDSARS. 
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General  Program  Information 
Each  of  the  programs  discussed  below  is  used  to  manipulate  the  data 
in  ED3ARS.  When  data  cards  are  to  be  read  into  the  system,  a  card  with 
"7 »  8  and  9"  punched  in  column  one  must  follow  the  main  body  of  the  program 
and  precede  the  actual  data  cards „  When  reading  General  Data  cards,  the 
last  card  should  have  a  '"99"  in  columns  seven  and  eight.  This  indicates 
end-of-data  to  the  system.  The  last  data  card  in  the  Zone-Grid  Coordinate 
File,  the  Parcel  Number-Building  Number-Address  File,  and  Parcel  Number- 
Grid  Coordinate  File  should  be  blank  to  indicate  end-of-data  to  the  system. 
The  last  data  card  is  followed  by  a  card  with  "6,  7,  8,  and  9"  punched  in 
column  one.  This  indicates  end-of- program  to  the  computer.  If  no  data 
cards  are  used  in  a  program,  the  "6,  7S  8,  and  9"  card  immediately  follows 
the  main  body  of  the  program. 

Data  File  Initialization 
Parcel  Number-Grid  Coordinate  File 

The  initialization  of  the  Parcel  Number-Grid  Coordinate  File  occurs 
first.  To  initialize  this  file,  the  coordinate  digitizer  of  the  Joint 
Highway  Research  Project  at  Purdue  was  utilized.  An  accurate  base  map  of 
the  entire  development  area  was  placed  on  the  digitizer  and  a  point  1,000 
feet  south  and  1,000  feet  west  of  the  southwestern  corner  of  the  development 
area  was  set  as  point  (0,0).  Key  points  on  the  base  map  were  digitized;  the 
digitizer  gave  readings  in  inches  and  these  readings  were  then  converted  to 
feet;  the  conversion  depended  upon  the  scale  of  the  map  utilized. 

The  key  points  digitized  were  the  intersection  of  street  center  lines. 
The  key  points  that  are  located  on  the  base  map  were  digitized  on  the  more 
accurate  maps,  and  the  coordinates  of  these  key  points  served  as  reference 
coordinates  for  the  digitizing  of  all  parcels „ 
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Each  map  to  be  digitized s  other  than  the  base  maps  was  first  broken 
up  into  parcels  and  approximate  centroids  located  as  shown  in  Figure  1. 
Consecutive  parcel,  numbers  are  then  written  on  the  map  for  each  parcel.  Trie 
map  is  placed  on  the  digitizer s  its  key  point  located  (for  coordinate 
conversion  to  the  base  system) s   and  then  each  parcel  eentroid  can  be 
digitized.  The  digitizer  will  punch  the  parcel  number  and  the  grid 
coordinates  on  an  IBM  card  which  can  then  be  fed  into  the  computer  for 
coordinate  conversion. 

The  data  cards  for  actual  initialization  of  this  data  file  are  read 
into  the  system  via  the  "initialize  Parcel  Number-Grid  Coordinate-File" 
Program.  The  data  cards  for  this  file  should  have  the  format  shown  in 
Figure  3°  This  figure  can  also  serve  as  a  sample  coding  sheet.  The  parcel 
number  is  placed  in  columns  1-6.  The  X  coordinate  is  placed  in  columns 
8-13s  ari<3.  the  Y  coordinate  in  columns  15-20.  When  more  information  becomes 
available ?  a  Program  titled  "Read  More  Information  For  The  Parcel  Number- 
Grid  Coordinate-File"  is  used.  This  data  file  locates  all  of  the  parcels 
in  the  development  area  and  coordinates  the  parcel  location  to  a  particular 
parcel  number.  This  number  is  the  identifying  tag  in  the  system  used  to 
locate  all  data  that  pertain  to  this  particular  parcel. 

Parcel  Number-Building  Number-Address  File 
The  Parcel  Number-Building  Number-Address  File  is  initialized  by 
putting  the  Parcel  Number  in  columns  1-6  and  the  Building  Number  in  columns 
20-21.  The  street  or  rural  route  number  is  placed  in  columns  22-27.  If 
the  parcel  is  a,   street  segments,  'the  block  number  is  placed  in  columns  20-26 
with  a  "B"  in  column  2'7  to  indicate  "street  block."  All  of  these  numbers 
should  be  right  justified.  Columns  30-69  contain  the  street  name  or  "Rural 
Route."  The  name  should  start  in  column  30  and  be  punched  on  the  card  just 
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as  It  appears  in  the  town  directory  with  one  column  between  each  word  in 
the  name.  The  type  of  street  is  coded  in  columns  70-72.  Format  for  this 
file  card  can  be  found  in  Fig„  3°  When  more  information  becomes  available 9 
a  program  titled  "Read  More  Information  For  The  Parcel  Number-Building 
Number -Address  File';!  is  used.  This  file  coordinates  each  building  9   vacant 
parcel  and  block  segment  with  a  particular  address  in  the  development  area. 

General-Data  File 

The  file  for  general  data  is  Initialised  after  each  parcel  In  the 
development  a,rea  has  been  given  a  unique  number.  The  format  for  General 
Data  cards  can  be  found  en  Figure  k;   this  figure  can  also  serve  as  a 
sample  coding  sheet.  The  01  card  is  used  for  every  parcel  in  the 
development  area.  The  02  card  is  used  where  the  parcel  has  a  use  other  than 
right-of-way.  A  12  card  is  used  in  place  of  the  02  card  when  a  parcel  is  a 
right-of-way.  If  the  parcel  has  multiple  land  use,  zoning  or  comprehensive 
land  use9  an  11  card  is  used  to  supplement  the  01  and  02  cards.  Each 
building  on  a  parcel  is  represented  by  the  information  on  the  03  card,  and 
each  establishment  (dwelling  unit,,  business 9  office 3  etc.)  in  a  building  is 
represented  by  an  Ok   card.  The  information  in  the  General  Data  File  is 
broken  into  three  categories.  The  first  category  is  land  use  information 
and  is  represented  by  the  Olj,  02  3  or  12s  and  11  cards;  the  second  category 
is  building  information  which  is  represented  on  the  03  card,  and  the  third 
category  is  establishment  information  which  is  represented  on  the  Ok   card. 

Each  data  item  in  the  system  is  given  a  specific  name.  This  name  is 
used  to  refer  to  the  particular  data  item  within  the  system. 

Each  building  on  a  parcel  is  given  a  number  to  uniquely  identify  it; 
if  four  buildings  exist  on  one  parcels  they  would  be  numbered  1-U.  Each 
establishment  within  a  building  is  also  given  a  unique  number  to  identify  it. 
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Building  numbers  start  at  one,  with  each  separate  parcel;  establishment 
numbers  start  at  one,  with  each  separate  building.  A  Program  titled 
"initialize  the  General  Data  File"  is  used  to  initialize  this  data  file  by 
reading  data  cards  and  writing  the  information  on  tape  and  paper  as  a 
check.  She  Program  "Bead  More  Information  For  the  General  Data  File'1  is 
used  to  read  in  more  information  as  it  becomes  available. 

Zone-Grid  Coordinate  File 
The  last  file  to  be  initiated  is  the  Zone-Grid  Coordinate  File.  To 
define  a  zone,  its  boundary  is  located  in  the  development  area  by  the  grid 
coordinate  system.  The  zone  is  broken  up  into  triangles  and  the  grid 
coordinates  of  each  of  the  three  vertices  are  coded  on  data  cards.  The 
card  format  is  shown  in  Figure  3»  An  example  of  a  zone  broken  into  tri- 
angles can  be  found  in  Figure  2.  She  coordinate  of  the  vertices  are 
placed  on  the  data  card  by  numbering  the  vertices  1-3.  Point  one  is  coded 
first s  followed  by  point  twos  point  three 9   and  point  one  again.  The  first 
and  last  coordinate  must  be  the  same  in  order  to  close  the  triangle.  The 
identifying  zone  name  is  placed  in  columns  1-12,  the  zone  number  is  placed 
in  columns  15-20.  The  coordinates  of  the  vertices  are  placed  in  columns 
22-80  in  the  format  shown  on  Figure  3«  The  zone  name  starts  in  column  1. 
The  zone  number  and  grid  coordinates  are  right  justified.  Program  "initialize 
'The  Zone  Name-Grid  Coordinate  File"  is  used  to  initialize  this  file  by- 
reading  data  cards  and  writing  the  data  on  tape,  and  paper  as  a  check.  To 
read  more  information  into  the  system  as  it  becomes  available  the  Program 
"Read  More  Information  for  the  Zone-Grid  Coordinate  File''1  is  used.  It 
should  be  noted  that  this  file  can  contain  as  many  zonal  systems  as  required 
by  the  users.  Census  Tracts,  Transportation  Zones,  School  Zones,  etc.  are 
all  examples  of  possible  zonal  systems  that  could  be  incorporated  into  this 
file.  The  inclusion  of  a  particular  zonal  system  is  dependent  upon  the 
potential  use  of  its  parcel  aggregation. 
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Read  Programs 
There  is  a  general  class  of  programs  in  EDSARS  that  will  read  the 
data  file  tape  and  print  the  information  on  paper .  These  programs  should 
be  used  after  reading  in  more  data  or  updating  the  system  to  check  the 
accuracy  of  the  tape  file.  These  programs  can  also  be  used  to  obtain  a 
complete  list  of  all  information  on  the  tape-  These  Read  Programs  will 
read  the  Parcel  Number-Grid  Coordinate  file  and  print  a  complete  list  of 
the  tape  file,  read  the  Parcel  Number-Building  Number-Address  file  and 
print  a  complete  list  of  the  tapes  read  the  General  Data  file  and  print  a 
complete  list,  read  the  Zone-Grid  Coordinate  file  and  print  a  complete 
listing  of  this  information. 

Update  Programs 

In  order  to  change  any  of  the  information  in  the  system  or  update  the 
informations,  a  set  of  update  programs  has  been  developed  to  replace  the  old 
information,  with  the  new.  This  is  accomplished  by  using  the  initializing 
programs  to  make  a  tape  file  of  the  new  information.  This  new  information 
file  and  the  original  file  are  then  used  to  initialize  a  new  tape  file  with 
all  of  the  new  information  incorporated  into  it. 

All  of  the  update  programs  require  that  the  new  data  cards  be  identical 
to  the  original  in  format.  The  new  cards  should  be  complete  -  all  information 
that  is  not  changed  should  still  be  punched  on  the  update  card.  The  new 
information  is  punched  on  the  card  replacing  the  old  in  the  same  format. 
These  cards  are  then  used  to  form  the  update  file.  Any  data  card  that  has 
no  data  changed  need  not  be  entered  into  the  update  file,  but  any  card 
that  has  any  piece  of  information  changed  must  be  completely  repunched  with 
all  of  the  new  and  unchanged  information. 
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Retention  of  Old  Data  Files 
A  decision  on  how  many  old  data  files  should  be  kept  needs  to  be  approach- 
ed at  this  time«  Data  files  represent  current  data  for  a  certain  period  of 
time.  The  comparison  of  data  files  for  different  time  periods  can  yield 
useful  information  on  trends  that  exist  in  the  development  area,,  It  is 
felt  that  files  should  he  updated  at  least  once  a  year*  These  yearly  files 
should  he  retained  for  at  least  a  period  of  five  years .  The  final  decision 
on  this  policy  iss  of  course ,  up  to  the  initializing  agency „ 

REERIEViJJ.  PROGRAMS 

To  retrieve  information  from  the  data  files  for  special  purposes,,  there 
are  a  set  of  programs  in  EDSARS  which  give  specific  information  for  the 
special  purposes  of  the  user.  The  following  programs  were  designed  to  he 
general  in  their  characteristics  so  that  specific  user  needs  could  be 
satisfied.  The  retrieval  programs  available  in  the  system  ares 

a.  To   retrieve  a  list  of  Y  arid  X* 

bo  To  retrieve  the  sum  of  Y  for  a  specific  X. 

c0  To  retrieve  a  list  of  Y  for  a  specific  X„ 

d„  To  retrieve  X  for  specific  parcel  numbers. 

e.  To  retrieve  a  parcel  number  and  building  number  for  a  specific 
address . 

f.  To  retrieve  a  list  of  parcel  numbers  for  a  specific  zone. 

C0HCLX3SI0HS 

The  following  conclusions  about  EDSARS  and  its  potential  can  be  made. 

1.  EDSARS  should  facilitate  effl  eient  and  economical  handling  of 
planning  data  for  an  area  of  about  100;, 000  population. 

2.  The  utilization  of  a  general  purpose  computer  and  general  purpose 
programming  languages  should  make  EDSARS  available  to  most  metropolitan  areas 
in  the  United  States. 
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3.  The  concept  of  a  unified  data  system  is  the  most  important  contri- 
bution of  EDSARS* 

ko     The  data  proposed  for  EDSARS  are  the  most  usable  and  easily  obtainable 
information  available  to  the  urban  area,, 

5*  The  incorporation  of  a  flexible  method  of  representing  zones  by 
their  location  is  essential  to  an  efficient  urban  data  system  such  as  EDGARS. 

6*  The  information  for  an  urban  data  system  should  be  in  three 
separate  files  so  that  one  file  can  be  updated  and  improved  without 
disturbing  the  other  files . 

7«  Zone  names  and  boundary  locations  should  comprise  one  file;  parcel 
numbers  and  parcel  location  comprise  another  file;  parcel  numbers s  building 
numbers ,  and  street  address  should  comprise  the  third  file;  and  the  fourth 
file  should  be  made  up  of  general  data., 

8*  The  best  unit  for  data  collection  is  the  parcel * 

9*  The  data  system  should  be  flexible  so  that  improvements  can  be 
made  as  used  and  technology  increases* 

10.  The  streets  and  rights-of-way  should  be  represented  as  special 
parcels  in  order  to  ensure  full  territorial  and  information  coverage* 

11*  All  data  incorporated  should  be  potentially  useful  and  updatable* 
12*  Utilization  of  applicable  theory  and  practical  experience  of 
existing  data  systems  are  needed  to  develop  a  useful*  efficient  and 
improved  data  system* 

The  concepts  that  are  represented  by  these  conclusions  when  tied 
together  into  an  urban  data  system  such  as  EDSARS  give  the  planning 
community  and  the  urban  environment  as  a  whole  a  flexible  and  useful  tool 
which  should  make  more  information  available  to  more  people  at  a  much  lower 
cost  and  with  much  less  effort* 
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It  is  Important  to  acknowledge  that  the  conceptual  technique  for 
retrieving  information  on  a  zonal  basis  through  the  use  of  coordinates  was 
developed  at  the  University  of  Washington  by  Mr,  Robert  B.  Dial.  The 
details  of  the  EDSARS  system,  Including  initialization,  update  and  retrieval 
programs,  codes  utilized  and  complete  descriptions  are  available  in  a 
Purdue  University,  Joint  Highway  Research  Project  Information  Report  No,  5j 
March  19680  Copies  are  available  at  the  cost  of  reproduction »  This 
project  was  funded  by  the  Public  Health  Service  through  the  Environmental 
Health  Institute  of  Purdue  University » 
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FIGURE    I.      SEPARATING      AN     AREA     INTO      PARCELS      FOR 
DATA     CODING 
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FIGURE   2.         ZONE      DIVIDED       INTO       TRIANGLES       FOR       DATA 
CODING 
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